Make enums serialize as strings if using the reflection-based serializer.#473
Conversation
eiriktsarpalis
force-pushed
the
reflection-use-string-enums
branch
2 times, most recently
from
b51df8a to
b2d6481
Compare
Will these changes to M.E.AI have any impact on users of the MCP SDK independently of the change in the PR? And does this mean we'd be inconsistent with using M.E.AI directly if we don't take this PR?
Can we somehow flip the default for the purposes of the MCP SDK? Could we make it an error either at build time or run time not to use |
This has been the behavior of MEAI for a while, it's just that the MCP SDK diverged in how it handles enums. I don't think there would be any inconsistency unless users call into MEAI components directly. FWIW I don't think that the MCP way is wrong or that the MEAI is right; this is just about enforcing a degree of uniformity.
The setting needs to be specified at compile time using APIs that the STJ source generator understands. Which means that users need to explicitly opt in to string enum serialization in their own configuration. |
halter73
left a comment
halter73
left a comment
There was a problem hiding this comment.
FWIW I don't think that the MCP way is wrong or that the MEAI is right; this is just about enforcing a degree of uniformity.
Given that this is more consistent with MEAI, I'm generally supportive of any change that defaults to string serialization of enums more often, particularly if there's any chance of interop with non-C# stuff.
eiriktsarpalis
force-pushed
the
reflection-use-string-enums
branch
from
b2d6481 to
732d20d
Compare
2 participants
While triaging #460 it occurred to me that Microsoft.Extensions.AI is enabling string-based enum serialization only when reflection-based serialization is turned on. This PR enables that behavior for MCP as well, however I'm not sure if it should be merged: it does introduce inconsistency between the reflection and source gen worlds after all.